Some database systems support temporal data management. Temporal tables differ from regular base tables in that temporal tables contain the “period” concept. In relational database systems, a period is represented by a pair of columns: the start column stores the start time of the period, and the end column stores the end time of the period. Temporal tables may contain different types of periods, such as a system time period, which is controlled by the database system, and a “business time period”, which is controlled by an application. Business time is sometimes referred to as “valid time” or “application time.” The values of the business time, i.e., the business start time and business end time, are provided by the users, and the business time tracks when the data is deemed valid in reality. For example, the business validity of data can be indicated by assigning a pair of date or timestamp values to the business time period of a row to indicate when the information is deemed valid. Rows in temporal tables can be inserted, updated, deleted, and queried using standard syntax. Referential integrity is the state in which all values of all foreign keys are valid. Regular, or non-temporal, referential constraint requires every row in a child table with non-null foreign key value to have one corresponding row in a parent table with a matching key value. However, database systems currently offer no mechanisms for enforcing temporal referential constraints for temporal tables with business time periods. For example, an administration system may need to ensure that every employee at every point in time during his or her employment belongs to a department that actually exists at that point. One possible approach is to build application logic to define and enforce the business rules that involve temporal referential integrity. However, this approach leads to more application complexity, places a burden on application developers, and negatively impacts the performance of the database system.